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INVENTORY TRANSACTION COMMON OBJECT 



CROSS REFERENCE TO RELATED APPLICATIONS 
[0001] This application claims the benefit of U.S. Provisional Patent Application No. 

60/457,359 filed March 24, 2003, entitled, "INVENTORY TRANSACTION 
SYNCHRONIZATION AND COMMON OBJECT," by Kahlon et al. } and which is hereby 
incorporated by reference in its entirety. 
TECHNICAL FIELD 

[0002] The present invention is directed to the field of data modeling in the context of 

enterprise resources planning, supply chain management, warehouse management, 
and customer relations management, and more specifically to inventory management. 
BACKGROUND 

[0003] Manufacturers and suppliers of products use back-office computerized systems 

to provide support for functions in enterprise resources planning (ERP), supply chain 
management (SCM) and warehouse management (WMS). Such functions include 
manufacturing, marketing, inventory control, procurement and financing. 

[0004] Also available are front-office computerized systems, which provide support to 

product vendors and distributors. In the context of inventory management, such front- 
office functions include analysis of historical customer demand for products, stocking 
and replenishment of inventory, and providing information resources for delivery of 
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[0005] 



inventory and service to consumers. In order to take advantage of such front-office 
software computerized systems, their users typically must store data in forms usable by 
the front-office computerized system, which often differ significantly from the forms 
usable with back-office computerized systems. 

Thus, when some or all aspects of inventory are managed by both back-office 
and front-office computerized systems, there is a need to synchronize the inventory 
information in both computerized systems. Generally, in order for front-office 
computerized systems to communicate with back-office computerized systems that are 
already being used, the user must manually regenerate data from the back-office 
computerized systems in forms usable by the front-office computerized systems, and 
vice versa. Such manual regeneration has several significant disadvantages, including: 
(1) it is often expensive; (2) it often requires a substantial amount of time to complete; 
(3) it must be repeated each time data changes in either the back-office system or the 
front-office system; and (4) it is prone to errors. 
[0006] In view of the foregoing, an automated approach for transforming data used by a 

back-office computerized system for use by a front-office computerized system, and 
vice versa, is needed. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0007] FIG. 1A is a high level network diagram showing aspects of a computerized 

environment in which the facility operates, according to certain embodiments. 
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[0008] FIG. 1 B is a block diagram that illustrates some business components of a front- 

office system 132, according to certain embodiments. 

[0009] FIG. 2 is a block diagram showing some of the components typically incorporated 

in at least some of the computer systems and other devices on which the facility 
executes. 

[0010] FIG. 3A is a high level flow diagram that shows some steps performed by the 

facility. 

toon] FIG. 3B is a flow diagram that illustrates further aspects of data integration 

operation, according to certain embodiments. 

[0012] FIG. 4 to FIG. 21 are data structure diagrams that illustrate the inventory 

transaction common object model, according to certain embodiments. 
DETAILED DESCRIPTION 

[0013] According to certain embodiments, the synchronization of inventory information 

addresses the needs of a company and its partners , which deploy multiple computer 
applications, obtained from multiple vendors of computer applications, in the company's 
inventory management system. The synchronization operation provides a user of the 
inventory management system the same view of the inventory information across the 
various computer applications. All changes in the inventory information need to be 
captured and made accessible to all relevant computer applications in the inventory 
management system. For example, when an inventory item is received into inventory, 
shipped for an order, or has a change in its availability status (such as "reserved" status 
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from "on hand" status), such inventory information need to be captured and made 
accessible to relevant computer applications in the inventory management system. 

[0014] For purposes of explanation, assume that a company's inventory management 

system includes a front-office system for customer interfacing operations. Further, 
assume that the company's inventory management system also includes a back-office 
system that includes an inventory cost accounting application, for example. The 
computer applications of the front-office system uses a data model that is distinct from 
the data model used in back-office system's computer applications. 

[0015] Inventory items are physically stored in a central distribution warehouse, at a field 

service office, in one or more field service engineer's trunk, or at a third party vendor's 
location. Assume that the various computer applications associated with inventory 
management used by the central distribution warehouse, the field service office, the 
field service engineer, and the third party vendor, are part of the front-office system. An 
inventory cost accounting application, for example, from the back-office system will 
need to share inventory information with the front-office system computer applications. 
Thus, a common data storage model is needed so that the various computer 
applications across the company's inventory management system can share the 
inventory information. 

[0016] When a front-office call center receives an order from a customer, the call center 

can commit the availability of inventory parts and labor to the customer even though 
such inventory parts are stocked by different partners across a multiplicity of systems, 
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only if the call center and the multiplicity of systems share inventory information. An 
important type of inventory information that needs to be shared across the systems is 
inventory transaction information. Thus, any inventory transaction information that 
occurs in the front-office needs to be synchronized with that of the back-office, and vice 
versa. Some examples of inventory transactions are shown in Table 1, herein, 
according to certain embodiments. 



TABLE 1 



# 


Transaction 
Type 


Description 


Triggers IAP 


1 


Keceive Ti or ii 
Third Party 


Parte rorpint frnm third narlv inx/pntorv 

location 


Svnchronize Inventorv 
Transaction 




Ship to Third 
rariy 


Dortc mn\/oH hpfu/ppn an nwnprl 
rdl lo iilUVcvJ utJiwcci I all uwi icu 

inventory location and a third party 

Inflation 


Synchronize Inventory 
Transaction 


3 


Adjustment 


Parts balance chanqes as result of Cycle 
Count 


Synchronize Inventory 
Transaction 


4 


Allocate 


Part moves from "on hand" status to 
"reserved" for same location 


Synchronize Inventory 
Transaction 


5 


De-Allocate 


Part moves from "reserved" status to "on 
hand" for same location 


Synchronize Inventory 
Transaction 


6 


Stock 
Transfer 


Parts moved between any two inventory 
location types 


Synchronize Inventory 
Transaction 


7 


Over-the- 
counter 


Parts moved between a warehouse and 
trunk inventory 


Synchronize Inventory 
Transaction 


8 


Receive 
Other 


Inventory transaction between any 
inventory location type and an external 
location 


Synchronize Inventory 
Transaction 


9 


Ship Other 


Inventory transaction between any 
inventory location type and external 
location 


Synchronize Inventory 
Transaction 


10 


Ship Internal 


Ship parts to an internal location 


Synchronize Inventory 
Transaction 


11 


Receive 
Internal 


Receive parts from an internal location 


Synchronize Inventory 
Transaction 


12 


Exchange 


Move parts between two trunk inventory 


Synchronize Inventory 
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between 
FSEs 


locations 


Transaction 



[0017] By ensuring that all the relevant systems in the enterprise have the same view of 

inventory transaction information, there is a seamless integration of inventory processes 
across all applications to maintain data integrity. Such data integrity with respect to 
inventory allows the front-office call center to check for inventory availability, to reserve 
and ship the inventory, etc. Another aspect of data integrity with respect to inventory is 
the integration of real-time consumption data. 

[0018] Thus, when all systems within the enterprise have a consistent and accurate 

view of the inventory information, then improvements in the following business aspects 
are possible: 

• Reduced spare parts inventory 

• Improved service delivery 

• Improved service assurance 

• Reduced dock space and labor to move product into reserve slots 

• Increase inventory turns and just-in-time deliveries 

• Transfer of ownership to suppliers (supplier consigned inventory on-site or direct 
deliveries) 

• Service reporting highlights unusual backorders 

• Line-item fill rates 

• Order fill rates to be used for analysis of underlying reason 

• Number of backorders and measure incomplete orders 
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• System on-hand equals actual on-hand 

[0019] Inventory transaction information records the movement of inventory items 

across inventory locations or, within an inventory location, across inventory levels. 
Inventory level is also known as a product bucket. Inventory level is a classification of a 
stock keeping unit, based on its availability code and status code. A stock keeping unit 
is an instance of a product (part number) at an inventory location. An example of a 
stock keeping unit is "30 GB Hard Drive" at "Chicago Field Office". Examples of 
availability codes are "on hand-good", or "on hand-defective", or "customer owned- 
good", etc. Every inventory transaction in the system updates the balances in the 
inventory location master for the product being transacted. As previously explained with 
reference to TABLE 1, there may be many different types of Inventory transactions. 

[0020] The inventory transaction of type "Allocate" will trigger the reservation of 

inventory against an order. The Allocate transaction occurs at order entry time when a 
customer calls the front-office call center to request additional inventory items 
(service/sales order). The call center representative will check the inventory (available- 
to-transact, i.e., if the inventory items are available on the shelf). If the requested 
quantity of inventory items is available in inventory, then the requested quantity of 
inventory items will be "reserved" for that order. The act of reserving a quantity of 
inventory items for an order is referred to as "allocate transaction", hereafter. Such 
allocate transactions will need to be synchronized with the back-office system so that 
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the correct quantity of inventory (for available-to-transact and reserved) is reflected in 
both the front-office and back-office systems. 

[0021] The allocate transaction may also originate in the back-office. Internal Orders 

(orders that transfer inventory between two inventory locations within a company, for 
e.g., from a warehouse to a field office) are created in the back-office. After an internal 
order is created in the back-office, the back-office system will designate the status of the 
requested quantity of inventory items to the "reserved" status. The reserved status 
information with respect to this particular requested quantity of inventory items need to 
be updated in the front-office application because these particular inventory items are 
no longer available to be allocated against a customer order in the front-office. 

[0022] The allocate transaction information includes information on the source location 

name, the product being allocated, the quantity of product being allocated, condition of 
the product being allocated (good/defective), and the order number against which the 
product is being allocated. 

[0023] Another type of inventory transaction is a "pick transaction". A pick transaction 

includes date and time, order number(s), part number, storage location (to the bin level) 
of the part, and location delivery information. The term "part(s)" is synonymous with 
"inventory item(s)", herein. Pick tickets are generated as part of the order fulfillment 
process. The order management process uses the mechanism of pick tickets to notify 
warehouse personnel that an order has been created and that such an order requires a 
specific group of parts to be shipped to the customer. For example, after the parts have 



EV 099149549 US 

Attorney Docket: 38481-8040.US01 



8 



been allocated against a customer order, a pick ticket is created and sent to the storage 
location that has such parts on reserve. A warehouse clerk (picker) receives the pick 
ticket and physically pulls the parts listed in the pick ticket, and moves such parts to the 
packaging/shipping area. The pick list on the pick ticket is sorted in the order in which a 
picker would navigate the inventory location. For example, the picker may navigate 
"aisle 1" then "aisle 4" then "aisle 5", etc. of the inventory location. Various route 
optimization routines for sorting the items on a pick list may be used. Such optimization 
routines may vary from implementation to implementation. 

[0024] Another type of inventory transaction is the "stock transfer" inventory transaction. 

The stock transfer inventory transaction may occur in either the front-office inventory 
system or the back-office inventory system. 

[0025] The stock transfer occurs when inventory items are pulled from one inventory 

location (source location) and are transferred to another inventory location (destination 
location). The source location and the destination location are usually in the vicinity of 
each other so that there is very little lag in time between when the inventory items leave 
the source location and when it arrives at the destination location. 

[0026] The information in a stock transfer transaction includes the source location name, 

the specific product, the quantity of inventory items transferred, the condition 
(good/defective) of the inventory item, and the destination location. If the inventory item 
is serialized, then an asset/serial number may be specified for the inventory transaction 
to commit in either the front-office or back-office inventory system. The number of 
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[0027] 



assets specified is equal to the quantity field in the inventory transaction. If the 
inventory item is being transferred to a customer (as in the case of a POS -point of 
sale- system), then the destination inventory location is designated as "External 

Location." 

Yet another type of inventory transaction is the inventory "receipt transaction." 
When inventory items are ordered from either an internal location or third party vendor, 
an inventory receipt transaction occurs when the inventory items arrive at the 
designated warehouse. The receipt transaction can occur at either the front-office 
inventory system or the back-office inventory system. When inventory items are 
received, the receiving clerk physically counts the quantity of inventory items received, 
notes the order number against which the inventory items are received, and notes the 
condition of the inventory items upon receipt. According to certain embodiments, the 
receive transaction in the front-office inventory system triggers synchronization with the 
back-office inventory system. According to certain embodiments, there may be three 
types of receive transactions: 1) "Receive from Third Party", 2) "Receive Internal", 3) 
"Receive Other". Any of the above three types of receive transactions can trigger a 
synchronization of the inventory transaction information between the front-office 
inventory system and the back-office inventory system. 
[0028] Another type of inventory transaction is the inventory "shipping transaction". The 

information with respect to the shipping of inventory items to customers are 
synchronized between the front-office inventory system and the back-office inventory 
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system. Such synchronization occurs after the Pick of the inventory items for a specific 
order has been completed, and after the inventory items for that specific order have 
been consolidated and packed. A shipment can contain inventory items from several 
pick tickets. It is possible for several shipments to be created for a single order. Thus, 
shipping documentation may be created at the order header or at line item level, for 
example. 

[0029] Another type of inventory transaction is the inventory "adjustment transaction". 

The inventory adjustment transaction occurs when an inventory administrator notices a 
discrepancy between the inventory balances that are recorded in the system versus the 
actual inventory balance. In response to such a discrepancy, an inventory adjustment 
transaction is made to correct the discrepancy. There may be multiple reasons for the 
discrepancy between the recorded inventory balance and the actual inventory balance. 
One reason may be the shrinkage resulting from inventory items being lost in transit, 
being scrapped, being stolen, etc. Thus, inventory adjustment transactions may be 
made at periodic intervals as result of the cycle count transaction. Also, inventory 
adjustment transactions may occur during an inventory audit. 

[0030] According to certain embodiments, the inventory adjustment transaction includes 

the source location name, the product, the quantity adjusted, the condition 
(good/defective) of the product, and the destination location (for accounting purposes). 
If the product is serialized, then an asset/serial number can be specified for the 
inventory adjustment transaction to commit in inventory system (both back-office and 
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front-office inventory systems). The number of assets specified is equal to the quantity 

field in the inventory transaction. 

Inventory transactions can be bi-directional. In other words, inventory 
transactions can be initiated from either the front-office inventory system or the back- 
office inventory system. When an inventory transaction is initiated, it returns a status of 
either success or failure. In case of failure, appropriate error handling procedure can be 
performed. 

The following illustrates the process by which the allocate transaction is initiated 
and generated in the front-office inventory system and then the allocate transaction is 
synchronized with the back-office inventory system. Such a synchronization is needed 
so that the correct quantity of inventory that is available-to-transact or that is reserved is 

reflected in both systems. 

Assume that the call center receives an order from customer X, for 25GB hard 
drive. The call center representative enters the order for customer X. The call center 
representative uses the front-office inventory system to specify a line item of 25GB Hard 
Drive and activates the locate functionality on the line item screen. The locate 
functionality displays that a 25GB Hard Drive is available in the Chicago Field Office. 
The inventory system's part locator engine knew that customer X was located in 
Chicago and was associated with the Chicago Field Office. 

The call center representative informs Customer X that the 25GB Hard Drive is 
available. The call center representative "allocates" the 25GB Hard Drive line item and 
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marks the order as Urgent. The call center representative reviews the shipping address 
and information with Customer X and tells Customer X that the order will be shipped to 
the Customer X from the Chicago field office according to the shipping method specified 
by Customer X. Next, the call center representative activates the picket ticket 
functionality on the order screen to generate a pick ticket that notifies the Chicago Field 
Office users that they need to send the order to Customer X. When the call center 
representative generates the allocate transaction in the front-office inventory system to 
reserve the 25GB Hard Drive for Customer X, a corresponding transaction is sent to the 
Integration server to notify the back-office inventory system that the 25GB Hard Drive 
has been put on reserve. Thus, the correct quantity of inventory that is available for 
further orders and that which is on reserve is reflected in both the front-office inventory 
system and the back-office inventory system. 
[0035] The following illustrates the process by which the allocate transaction is initiated 

and generated in the computerized back-office inventory system and then the allocate 
transaction is synchronized with the computerized front-office inventory system, 
according to certain embodiments of the invention. 
[0036] Assume that the manager (Mr. M) of the company's central warehouse in Dallas 

uses an enterprise resource planning (ERP) system to manage inventory and 
warehouse operations. The ERP system is the back-office system for this example. 
One of Mr. M's responsibilities is to ensure that enough spare parts (inventory items) 
available at the field offices across the country to provide desired service levels to 



are 
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regional customers. Assume that when a service order cannot be sourced from a 
regional field office, the service order is sourced from the company's Central 
Warehouse. It is Mr. M's objective to ensure that the majority of service orders are 
sourced from regional field offices so that his company can provide prompt response to 
its customers and meet service level agreements. Further assume that the field offices 
are using a computerized front-office inventory system. Mr. M uses the front-office 
inventory system to monitor the inventory levels across the field offices. Assume that 
Mr. M notices that the Chicago field office is running low on 25GB Hard Drives for AIX 
servers. Mr. M uses the replenishment process in the front-office inventory system in 
order to generate an internal order from the Dallas central warehouse to the Chicago 
field office. At such time, an application service interface (ASI) is invoked to transmit 
that order to the ERP system (back-office inventory system) at the Dallas Central 
Warehouse. 

[0037] Next, Mr. M uses the ERP application to reserve, via the allocate transaction, the 

requested quantity of 25GB Hard Drives. Mr. M also generates a pick ticket at the 
Dallas central warehouse. When the allocate transaction is committed in the ERP 
application, the inventory integration server receives an allocate transaction message. 
This allocate transaction message is transmitted to the front-office inventory system and 
an appropriate allocate transaction is generated in the front-office inventory system 
database. Thus, the correct quantity of inventory that is available for further orders and 
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that which is on reserve is reflected in both the front-office inventory system and the 

back-office inventory system. 

A software facility (hereafter "the facility") for automatically converting inventory 
transaction information, is described. In some embodiments, the facility converts 
inventory transaction information from a form used by the source system to a form used 
by the target system. In certain embodiments, back-office systems are those that 
provide support for such functions as manufacturing, marketing, inventory control, 
procurement and financing. In certain embodiments, front-office system are those that 
provide support for such functions as analysis of historical customer demand for 
products, stocking and replenishment of inventory, and providing information resources 
for delivery of inventory and service to consumers, and sales. It is to be noted that the 
passage of inventory transaction information can be bi-directional. In other words, 
inventory transaction information can be passed from the back-office inventory system 
to the front-office inventory system or vice versa. When inventory transaction 
information is passed from the back-office inventory system to the front-office inventory 
system, then the back-office inventory system is referred to as the source system and 
the front-office inventory system is referred to as the target system. On the other hand, 
when inventory transaction information is passed from the front-office inventory system 
to the back-office inventory system, then the front-office inventory system is referred to 
as the source system and the back-office inventory system is referred to as the target 
system. 
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[003 9] In some embodiments, such as embodiments adapted to converting inventory 

transaction information in the first source format, the facility converts inventory 
transaction information by converting the inventory transaction information that is in the 
first source format into an intermediate format. The intermediate format is then used to 
convert the inventory transaction information into the target format. 

[00 40] By performing such conversions, embodiments of the facility enable a user of a 

first computerized system who has stored inventory transaction information in a first 
format for use by the first computerized system to readily make the stored inventory 
transaction information available for use in a second computerized system that utilizes a 



[0041] 



second format in a cost-efficient and time-efficient manner. 

FIG. 1A is a network diagram showing aspects of a typical hardware environment 
in which the facility operates. FIG. 1A shows a source system 110, a target system 
130, an integration server 120 and a network 150. Source system 110 stores inventory 
transaction information in a source format. There may be more than one source 
system. Target system 130 stores inventory transaction information in a target format. 
There may be more than one target system. 
[0042] The facility (not shown) converts some or all inventory transaction information 

that is in the source format into the target format by using an intermediate format of the 
inventory transaction information. In certain embodiments, such conversions are 
performed with the aid of one or more other computer systems, such as integration 
server system 120. Components of the facility may reside on and/or execute on any 
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combination of these computer systems, and intermediate results from the conversion 
may similarly reside on any combination of these computer systems. 

[0043] The computer systems shown in FIG. 1A are connected via network 150, which 

may use a variety of different networking technologies, including wired, guided or line- 
of-sight optical, and radio frequency networking. In some embodiments, the network 
includes the public switched telephone network. Network connections established via 
the network may be fully-persistent, session-based, or intermittent, such as packet- 
based. While the facility typically operates in an environment such as is shown in FIG. 
1A and described above, those skilled in the art will appreciate the facility may also 
operate in a wide variety of other environments. 

[0044] FIG. 2 is a block diagram showing some of the components typically incorporated 

in at least some of the computer systems and other devices on which the facility 
executes, including some or all of the server and client computer systems shown in FIG. 
1A. These computer systems and devices 200 may include one or more central 
processing units ("CPUs") 201 for executing computer programs; a computer memory 
202 for storing programs and data - including data structures - while they are being 
used; a persistent storage device 203, such as a hard drive, for persistently storing 
programs and data; a computer-readable media drive 204, such as a CD-ROM drive, for 
reading programs and data stored on a computer-readable medium; and a network 
connection 205 for connecting the computer system to other computer systems, such as 
via the Internet, to exchange programs and/or data - including data structures. While 
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computer systems configured as described above are typically used to support the 
operation of the facility, those skilled in the art will appreciate that the facility may be 
implemented using devices of various types and configurations, and having various 
components. 

[0045] It will be understood by those skilled in the art that the facility may transform 

inventory transaction information from a number of different source systems and from a 
number of different source software packages to a number of target systems and/or to a 
number of target software packages. 

FIG. 1 B is a block diagram that illustrates some business components of a front- 
office inventory system 132. According to certain embodiments, such business 
components include a central distributing warehouse 152, a multiplicity of field offices 
154, 156, a plurality of trunks, such as trunk 158, and one or more call centers, such as 
call center 160. Such business components in front-office inventory system 132 use 
and store inventory transaction data in the front-office system format. Further, one of 
the primary functions of front-office inventory system 132 is to serve and interface with 
customers 162. 

[0046] FIG. 3A is a high level flow diagram that shows some steps typically performed 

by the facility in order to convert inventory transaction information from the one or more 
source formats to the target format. At block 301, the facility extracts inventory 
transaction information from one or more source systems. At block 302, the facility 
converts the extracted information into an intermediate format. The intermediate format 
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[0047] 



[0048] 



is described in greater detail herein, with reference to the common object data model. 
At block 303, the facility synchronizes the inventory transaction information from the 
source system with that of the target system by converting the inventory transaction 
information in intermediate format into the target format. After block 303, the steps as 

shown in FIG. 3A conclude. 

FIG. 3B is a flow chart that illustrates further aspects of the data integration 
operation, according to certain embodiments. Because the passage of inventory 
transaction information can be bi-directional, the back-office inventory system is referred 
to as the source system and the front-office inventory system is referred to as the target 
system when inventory transaction information is passed from the back-office system to 
the front-office system. However, when inventory transaction information is passed 
from the front-office system to the back-office system, then the front-office system is 
referred to as the source system and the back-office system is referred to as the target 
system. 

In FIG. 3B, at block 310, a source application specific adapter listens for the 
"create" inventory transaction messages from a source application program in the 
source system. According to certain embodiments, the source system is configured 
with a triggering mechanism that sends a message to the integration server when the 
inventory transformation information is created in the source system. At block 312, a 
source application specific object (source ASO) that is associated with the message is 
extracted. At block 314, the source application specific adapter passes the source ASO 
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to a source application transformation business process (SATBP) across an application 
specific interface (ASI). At block 316, the SATBP maps the source ASO to the 
inventory transaction common object model (COM) to create a corresponding inventory 
transaction COM instance. At block 318, the inventory transaction COM instance is 
passed to the Create Inventory Transaction Integration Application Process (CITIAP), 
via the common service interface (CSI). At block 320, the CITIAP passes the inventory 
transaction COM instance to the target application transformation business process 
(TATBP), via CSI. At block 320, the TAT BP transforms inventory transaction COM 
instance to the target system's application specific object (target ASO). In other words, 
in the case where the source system is the back-office system, then the COM instance 
is converted into a message that is associated with the integration system, such as a 
multi-application integration system (MAIS), for pushing to the front-office system. In 
the case where the source system is the front-office system, then the COM instance is 
converted into a suitable message that can be pushed to the back-office system. At 
block 322, the TATBP invokes the target application specific adapter via the ASI to push 
the inventory transaction information (message) into the target system. According to 
certain embodiments, inventory location information and product information may need 
to be extracted from the inventory transaction information for purposes of pushing the 
inventory transaction information into the target system. At block 324, the TATBP again 
invokes the target application specific adapter via the ASI to commit the inventory 
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[0049] 



[0050] 



transaction into the target system. Thus, the inventory transaction information in the 
target system is synchronized with that of the source system. 

The Create Inventory Transaction is the process of replicating an Inventory 
Transaction from the source system into the target system. In the scenario going from 
the back-office to the front-office, the Create Inventory Transaction IAP requests an 
asynchronous creation of an inventory transaction and does not expect a synchronous 
response. In the scenario going from the front-office to the back-office, for 
movement/adjustment/miscellaneous inventory transactions, the Create Inventory 
Transaction IAP requests synchronous creation of an inventory transaction. 

Create means that once a transaction is created in the target system, it is 
committed and may not be updated. Once committed, the transaction updates the 
balance in the inventory location master for the bucket that is targeted and for the 
product that is being transacted. If the user tries to create an Inventory Transaction that 
already exists in the target system, the Create Inventory Transaction IAP will simply 
error out. 

[0051] FIG. 4 to FIG. 21 are data structures of the inventory common object model 

associated with inventory transactions. Such an inventory common object model 
illustrates sample intermediate data structures produced from corresponding inventory 
transaction information in the source format. 

[0052] In FIG. 4, the intermediate data structure 400 is of type 

listOflnventoryTransaction, which may contain any number of inventoryTransaction data 
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structures 



410. One such illustrated inventoryTransaction data structure 500 is shown 



[0054] 



in FIG. 5. 

In FIG. 5, inventoryTransaction data structure 500 is the inventory transaction 
root element and includes an inventory transaction identifier 502 (ID), a baseData 
section 504, a listOfldentif.erData section 506 (list of identifier data within this particular 
inventory transaction), a locationData 508, a relatedProduct 510 (product or item related 
this particular inventory transaction), and a relatedDocumentData 512. In FIG. 5, 
inventoryTransaction data structure 500 may also include various other information 
such as various inventory transaction customData 514. The baseData section 504 is 
discussed in greater detail herein with reference to FIG. 6. The listOfldentifierData 
section 506 is discussed in greater detail herein with reference to FIG. 7. The 
locationData 508 is discussed in greater detail herein with reference to FIG. 8. The 
relatedProduct 510 is discussed in greater detail herein with reference to FIG. 9. The 
relatedDocumentData 512 is discussed in greater detail herein with reference to FIG. 

10. 

FIG. 6 illustrates the baseData section. In FIG. 6, the baseData section 600 
includes transaction Comments 602, a transaction Date 604, a Quantity 606 (quantity of 
products or items included in the transaction), a transaction Time 608, a typeCode 610, 
which is the type of transaction, i.e., "Receive Other, "Ship Other, etc., and a 



uni 



tOfMeasureCode 612 ( basic unit of measure code). 
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[0055, FIG. 7 illustrates the listOfldentif.erData section, which is a list of identifier data 

for items within the particular inventory transaction. In FIG. 7, the listOfldentif.erData 
section 700 includes any number of identifierData 710, which are identifier data specific 



[0056] 



[0057] 



[0058] 



[0059] 



to a product or item. 

FIG. 8 illustrates the locationData section. In FIG. 8, the locationData section 
800 includes destinationData 802 and sourceData 804. The destinationData 802 is the 



The 



destination location data specific to the particular inventory transaction. 
sourceData 804 is the source location data specific to the particular inventory 

transaction. 

FIG. 9 illustrates the relatedProduct section, which is the product or item related 
to the particular inventory transaction. In FIG. 9, the relatedProduct section 900 
includes a product or item identifier (ID) 910 for the inventory transaction. 

FIG. 10 illustrates the relatedDocumentData section. In FIG. 10, the 
relatedDocumentData section 1000 includes a relatedPurchaseOrder 1010, which is a 
reference to the order line related to the particular inventory transaction. 

FIG. 1 1 illustrates the identifierData section, which is the identifier data specific to 
the product or item. In FIG. 1 1 , the identifierData section 1 1 00 includes a serial number 

for product or item (ID) 1110. 
[0 o60] FIG. 12 illustrates the destinationData section, which is the destination location 

data specific to the particular inventory transaction. In FIG. 12, the destinationData 
section 1200 includes a destination bucketCode 1202 and a destination relatedlnvLoc 
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1204. The destination bucketCode 1202 is a destination bucket code, such as "On 
Hand Good", "On Hand Defective", "Customer Owned Good", "Customer Owned 
Defective", "In Transit Good", and "In Transit Defective." The destination relatedlnvLoc 
1204 is a destination inventory location identifier. 

FIG. 13 illustrates the sourceData section, which is the source location data 
specific to the particular inventory transaction. In FIG. 13, the sourceData section 1300 
includes a source bucketCode 1302 and a source relatedlnvLoc 1304. The source 
bucketCode 1302 is a source bucket code, such as "On Hand Good", "On Hand 
Defective", "Customer Owned Good", "Customer Owned Defective", "In Transit Good", 
and "In Transit Defective." The source relatedlnvLoc 1304 is a source inventory 
location identifier. 

[0062] FIG. 14 illustrates the relatedPurchaseOrder section, which is a reference to the 

order line related to the particular inventory transaction. In FIG. 14, the 
relatedPurchaseOrder section 1400 includes purchaseOrder 1410, which is the related 
order line identifier. 

[0063] FIG. 15 illustrates the destination relatedlnvLoc section, which is the destination 

inventory location identifier. In FIG. 15, the destination relatedlnvLoc section 1500 

includes a destination inventory location ID number 1510. 
[0064] FIG. 1 6 illustrates the source relatedlnvLoc section, which is the source inventory 

location identifier. In FIG. 16, the source relatedlnvLoc section 1600 includes a source 

inventory location ID number 1610. 
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FIG. 17 illustrates the purchaseOrder section, which is the related order line 
identifier for the particular inventory transaction. In FIG. 17, the purchaseOrder section 
1700 includes a common object row ID 1702, a purchase order baseData 1704, a 
listOfPurchaseOrderLineltem 1706 (a list of purchase order line item), and a purchase 
order customData 1708 (purchase order custom data). 

FIG. 18 illustrates the purchase order baseData section. In FIG. 18, the 
purchase order baseData section 1800 includes a purchase order Number 1810. 

FIG. 19 illustrates the listOfPurchaseOrderLineltem section, which is a list of 
purchase order line items. In FIG. 19, the listOfPurchaseOrderLineltem section 1900 
includes any number of purchaseOrderLineltem 1910 (purchase order line items). 

FIG. 20 illustrates the purchaseOrderLineltem section, which is the purchase 
order line item. In FIG. 20, the purchaseOrderLineltem section 2000 includes a 
purchase order line item number ID 2002, a purchase order line item baseData 2004, 
and a purchase order line item customData 2006 (purchase order line item custom 
data). 

FIG. 21 illustrates the purchase order line item baseData section. In FIG. 21, the 
purchase order line item baseData section 2100 includes a purchase order line item 
Number 21 10. 

It will be appreciated by those skilled in the art that the above-described facility 
may be straightforwardly adapted or extended in various ways. For example, the facility 
may be used to transform various other kinds of inventory transaction information, and 
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may 



be used to transform inventory transaction information between a variety of other 



formats. 

In the foregoing specification, embodiments of the invention have been described 
with reference to numerous specific details that may vary from implementation to 
implementation. Thus, the sole and exclusive indicator of what is the invention, and is 
intended by the applicants to be the invention, is the set of claims that issue from this 
application, in the specific form in which such claims issue, including any subsequent 
correction. Any express definitions set forth herein for terms contained in such claims 
shall govern the meaning of such terms as used in the claims. Hence, no limitation, 
element, property, feature, advantage or attribute that is not expressly recited in a claim 
should limit the scope of such claim in any way. The specification and drawings are, 
accordingly, to be regarded in an illustrative rather than a restrictive sense. 
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